@nsmith said in spidev fails: I think the HW SPI is only used during boot up to read the OpenWRT kernel code from the flash into RAM, after that i believe its not used at all, otherwise the SPI would be un-usable. I really hope this is true becuase I'm already lacking 4 GPIO pins, if I have to give up more pins to a bitbanged SPI then my project will be over. hopefully not, but: The SPI is used for loading the bootloader from flash (without any driver, this part is hard-wired in the MT7688), then the bootloader (u-boot) will load the Linux kernel from flash using its own flash driver. But from then onwards the linux kernel will still access the flash whenever it needs to read or write to a file that is not on the ramdisk (which is - pretty everything except from /tmp and /var). Of course, there is some caching, so not every tiny file access will always access flash, but still in many cases. Depending on what your overall application does, there might be very little file accesses, but avoiding them entirely (from linux services running in the background, responding to network, keeping WiFi connections, serving web requests or ssh etc.) would mean you need to strip down OpenWrt severely, essentially killing all services except for your own app, or transplant everything to the ramdisk. Maybe possible, but far from a no-brainer. (Btw: sysupgrade needs to do the ramdisk transplant thing when it replaces the firmware, so one could glean some ideas from there - complicated beast though, too.) Unfortunately, it seems to me not even the "switch everything to SW-SPI" trick you posted can help here, because after that you'll still be sharing the SPI bus with the flash chip, only that flash accesses now take 40 times more time Maybe, when you run out of GPIOs, a I/O extender chip like MCP23S17 might be far easier than too much struggle trying to re-use those HW SPI pins in any way. These are good for half-duplex SPI devices that need high bandwidth but no real time bus availability, such as a LCD display (and the internal flash), but for nothing else.

@rahul2413 looks like you're trying to do a full-duplex SPI transaction. The Omega2 family does not support full-duplex on the hardware SPI bus. Half-duplex transactions will work fine. More details in this FAQ post. If you absolutely need full-duplex, you can try using a software-based SPI bus.

First check device id and bus-id you are using during the initialization of spi (i.e. onionSpi.OnionSpi(1, 32766) SPI is done through an adapter usually found at /dev/spidevX.Y where X is the device number and Y is the bus number, so in my case 1 is bus id and 32766 is device id you can find your details under : /dev/ folder of your omega where file spidev would tell details for you as in above line or at below official ref. Use Ref: https://docs.onion.io/omega2-docs/spi-python-module.html hope you have resolved, if still any issue please revert here... Thanks